A critical function of identity management (IdM) systems is the ability to ensure that each domain user account has only the privileges allowed by business policy controls. To detect these access authority violations, it is essential that an IdM system detect changes to the managed systems, such as Windows Active Directory by Microsoft, and assess the changes against the business policy controls.
Active Directory is particularly difficult to monitor for access authority changes. When an Active Directory user account is added or removed from security groups, for example, the actual object that is affected is the group (member list). The user account is not directly updated and therefore the typical IdM change log monitoring of the user accounts does not detect security group changes.
Approaches to address this shortcoming are computationally inefficient or not appropriate for use with IdM systems. Active Directory LDAP change notification is an approach that requires the user to register with the domain controller to receive change notifications. The notifications are based on an LDAP search filter and are relative to a single base point. Due to the overhead required, it is not recommended to use Sub Tree scope. In addition, Sub Tree scope is only supported at the root node. This means that a notification result would be generated for every changed object in the domain resulting in notification of a many thousands of irrelevant events. There is also a severe performance impact on Active Directory, particularly the significant overhead on the domain controllers. As stated in Microsoft's online help for Visual Studio:                “Although the subtree scope is supported if the base object is the root of a naming context, its use can severely impact server performance, because it generates an LDAP search result message every time an object in the naming context is modified. You cannot specify LDAP_SCOPE_SUBTREE for an arbitrary subtree.”        
Another approach uses the DirSync search control of Active Directory, which requires a full search request after which a “cookie” that is used for subsequent searches is received. By presenting the cookie on a subsequent search, only objects changed since the last search are returned. The approach is not suitable for use by an IdM because it does not detect changes to the user access authority changes (i.e. changes to the group membership). When a user object is added or removed from a group (thus affecting the “memberOf” attribute), that user object is not reported as changed. This type of search will return the group object, since it was the group object that actually changed (member list updated). The change event does not contain details on the addition and removal of the members. This information can only be determined by maintaining a local copy of the member list and performing a before/after comparison with the current list. Since many groups contain most or all of the user objects (e.g. Domain Users), there could be potentially millions of member entries to compare.